微服务实施从数据梳理开始

作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心

前面我们讨论并澄清了微服务的一些概念，是从全局的角度来考虑的。（点击可回顾如何看懂百花齐放的微服务？）不管概念再好，总是要落地的，一旦具体到实施，总会有这样那样的问题。在网上看到有人说ESB是大坑，千万不要碰ESB，不过在我们看来，微服务也是坑，那你跳还是不跳？一个事物总会有正反两面，我们在宣传的时候往往只说其正面性，有意忽略其反面性，但不能因为其有缺点就否定它，那就不是辩证的看待问题了。所以在面对这些新概念的时候，需要我们通过表面看到其实质，了解其好的特性，好的一面，也理解其缺点和不足，差的一面。ESB是有其不足，但它是实现业务集成、系统集成、数据集成的重要方式。之所以反馈不好，很大程度上是对其认识和实施的不到位。微服务也是一样，每种技术的产生都有其历史原因，都解决一定的技术问题，不能求全责备。每种技术也都会有其历史定位。

说起微服务，很多人都会说SpringCloud、Dubbo是微服务，我们在容器云交流过程中说要支持微服务，不少厂商说他们支持SpringCloud，支持Dubbo。我们提出这个问题，是希望在实施之前理清这些概念，概念清楚了、理解了，认识到了其本质，后面的实施就不会走错路、走弯路。

一、SpringCloud不是微服务

SpringCloud网站的解释是SpringCloud为开发人员提供了在分布式系统中快速构建一些通用模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选择、分布式会话、集群状态），使用SpringCloud，开发人员可以快速地完成实现这些模式的服务和应用程序。SpringCloud是个工具，一个开发框架，使用它可以构建微服务，但它不是微服务。Dubbo也是一个基于Java技术的RPC框架，可以用它来实施微服务。那用SpringCloud、Dubbo开发的服务是不是微服务呢？在我们看来，也不一定是微服务。

二、SpringCloud开发的服务也不一定是微服务

微服务要求有自己独立的数据库，目的是最终要实现数据的唯一来源。这也是微服务实施的难点之一。前面我们也讨论过，如果有主数据系统，实施微服务可能会简单些，因为不需要考虑业务数据的梳理了。如果仅仅是用SpringCloud开发服务而不去梳理业务数据，依旧采用传统数据库数据存储方式，其实跟ESB服务思想没有太大差别。业务应用/服务的瓶颈依然存在。数据是核心，不管什么服务形式，“服务”只是载体，是服务于数据的。所以，不管ESB或者主数据系统，如果做过相应的业务数据梳理，将有助于我们实施微服务。所以你看，ESB也不是一无是处，每种技术的产生都有其价值。

所以关键不在于我们使用什么样的工具，工具只是协助我们快速的构建服务。重点是我们要采用的、要实施的是微服务，这种分布式、松耦合、组件化的架构帮我们解决了单体应用大而难以维护、难以快速响应需求变化的问题。它是一种新的系统架构方式，独立自治，有自己的数据库，通过统一的服务接口来访问数据，不允许直接访问数据库。所以满足微服务特性要求的服务才能称为微服务，而不在于用什么工具开发的服务。

所以能支持SpringCloud，或者能支持SpringCloud开发的服务，也不一定是就能支持微服务。微服务当然也不只是用SpringCloud、Dubbo来开发实现。所以，容器云平台在支持微服务的时候，就要求不只是着眼于SpringCloud或Dubbo，而是能够支持满足微服务定义的微服务。

三、数据是核心，采用微服务，从数据梳理开始

以前的文章中我们也提到微服务要求对业务系统的彻底改造。但业务系统改造往往牵一发而动全身，不说不可能，往往也是很难很难。所以更多的是在实现新的业务需求时，才考虑微服务等新的技术。当然，这是采用微服务很好的切入点。

微服务实施是个长期的过程，可能需要几年的时间来完成单体应用改造，特别是传统行业技术力量比较弱，采用微服务是个很大的挑战，仅靠厂商也很难实施成功，必须培养自己的研发技术力量。

微服务比较适合分布式互联网类应用，这类应用需求变化快，这就要求业务应用的迭代要够快。微服务要求数据实体分离独立、数据服务组件化、业务应用通过数据服务接口来调用交换数据。业务应用的变化迭代往往不会影响到数据服务和数据服务接口，只是对数据服务的重新编排组合，输出新的业务应用。

Johannes Giani 《6 Things to Consider for Microservice Migration》提到两层微服务和全栈微服务（图1），和我们的想法类似。底层是数据，这里的Application是我们所说的微服务，Presentation是基于微服务的我们所说的业务应用，可以是Web应用、手机应用、桌面应用等。实际业务场景中一个微服务很难独立构建一个业务应用系统，往往需要很多个微服务来共同构建（图2）。

图 1 两层微服务和全栈微服务

图 2 我们理解的微服务

其实不管几层微服务，数据基础，是核心。要实现微服务，首先得对数据进行梳理、分拆、清洗、去冗、充实等。我们以前也提到过，如果数据治理的好，实施微服务会相对容易，也是基于这样的原因。相当于站在了巨人的肩膀上，就会看的更高更远，实施起来会更容易。最终以服务的方式把一致的、完整的、准确的、单一来源的、具有权威性的数据传送给企业内需要这些数据的各种业务应用系统。

四、数据梳理其实就是业务梳理过程

采用微服务，业务梳理是需要的，但往往难以进行完整的业务梳理。特别是传统企业，业务人员和IT技术人员代沟太大，把业务梳理清楚几乎是一个不可完成的任务。但是又不能不去做，不能坐等机会的流逝。所以我们建议可以从下往上，先从数据层进行数据梳理。所以我们说新业务需求采用微服务是一个很好的切入点。对新的业务需求的分析正好可以实现对数据的初步梳理。比如开始时间字段，在某个系统中可能是String类型，在另一个系统中可能是Int类型，在第三个系统中可能是Date类型，或者DateTime，或者Timestamp类型等；还有就是虽然是同一个字段名，却表示不同的涵义，比如风险级别，在不同系统表示不同的涵义，取值也不同。这些信息都需要理清楚，然后考虑数据标准化。不要奢望一蹴而就、一次就完成数据的梳理，那是丰满的理想。骨干的现实是新的业务需求往往时间紧、任务重，不会让你慢慢的去梳理数据。但是新业务用到的数据实体，用到的实体属性，属性类型，取值范围，在哪些系统中用到了同样的数据实体，属性、类型、取值范围等有什么不同等等还是可以收集起来，建立初步的数据模型，在以后的工作中逐步完善数据模型，以小步快跑的方式快速熟悉和构建微服务体系，构建业务应用系统。

不过幸运的是目前大部分公司都有了相应的数据基础，数据标准、数据规范和数据管理系统，很少有需要从头再来的，基于这些基础来建立数据模型，有助于微服务的体系的快速构建。

五、数据模型

数据模型是数据管理体系中重要的一部分，是数据治理的关键和重点。这也是我们前面文章中提到采用微服务对数据治理能力要求比较高的原因之一。数据梳理过程中，要逐步建立数据模型。基于这些模型来构建单体微服务。

图 3 微服务模型示意

借用Chris Richardson在《Introduction to Microservices》的图来说明一下。理论上，微服务数据模型应该能表示整个企业的业务范围内的重要数据元素及他们之间的关系。但是，最初可能无法做到。利用主数据系统建设的经验，可以以某一系统为基础，逐步完善这些数据模型，然后推广到整个企业。比如我们公司有大大小小的系统上百个，各有各的历史原因、现实情况，想去立刻实现一个公司级的模型，那是绝无可能的，但又不能不做。服务化的思想就是稳步推进、持续改进、逐步完善。数据梳理和数据模型建设也是一样，需要不断的持续改进，持续优化。

通过数据梳理——建立数据模型——构建微服务——建设业务应用系统——接口改进（数据梳理——更新数据模型——更新微服务——更新业务应用系统）流程可以持续的优化和完善微服务体系，更好的满足业务需求。

六、内部输出数据模型

我们的目标是构建公司级的微服务体系，这样才能真正体现微服务架构的价值。所以经验要与其他团队及时分享，模型和微服务需要及时输出。其他团队的需求也是改进和完善的动力。遵从一致性的数据模型，将会令数据标准变得更有价值，将会令微服务更快成熟和完善。

七、建立枚举常量数据字典中心

业务应用中用到的枚举常量值是我们系统建设中不可避免的数据。这些数据变动很小，但由于系统建设的历史原因，各个系统同一字段表示的意义可能不同，取值范围可能不同，顺序编号也可能不一样，这就为公司的数据标准化工作带来了困难。比如性别，很简单，一个系统中可能是（男、女），一个系统中可能是（0、1）表示男女，一个系统中可能是（男、女、其他）等等，构建微服务的时候就需要采用标准的数据定义，涉及和其他系统集成的，临时方案需要考虑采用ESB的方式来实现一个Adapter适配器做转换。等将来系统被微服务替换掉了，就可以完全微服务化，也就不需要Adapter来转换了。

公司范围内的枚举常量往往会不少，比如民族、国籍、性别、类型（客户类型、账户类型、产品类型……）、级别（风险级别、客户级别、服务级别……）等，这些枚举常量可以考虑在建立一个枚举常量数据字典中心来统一管理，对应的可以构建一个基础的枚举常量数据字典微服务。这就是基础的、需要共享的微服务。

八、尽可能利用公司已有的数据系统资源

很多公司其实都或多或少的已经有了自己的相应的数据管理平台或系统，比如元数据管理系统、主数据管理系统、数据标准和规范、数据安全和管控规范、数据模型等，在采用微服务和构建微服务时，要尽可能的充分利用公司已有的数据管理系统和资源，不要再尝试建立一套数据模型或规范。不适合的可以持续改进，不要出现九龙治水的局面。构建微服务系统很重要的是要考虑实现数据的单一来源，配合数据管理和数据治理的工作，更好的服务于企业的业务需求。

九、小步快跑

采用微服务之后，微服务的实施是个长期的工作，需要持续的改进，逐步进行系统改造。对于新的业务需求，尽可能采用微服务架构，对于不能采用微服务或不能改造的应用，先以adapter方式集成，数据修改可以采用主数据管理系统的方式，实现系统间数据同步。

在实施过程中，工具、方法、人员会逐步的磨合成熟，所以要先做起来，在做的过程中逐步的改进，逐步的优化。这是一个量变到质变的过程，坚持就会收获微服务架构带来的优势。

参考文献

1.Johannes Giani 《6 Things to Consider for Microservice Migration》
2.Chris Richardson 《Introduction to Microservices》
3.Pivotal projects.spring.io/spring-cloud/

更多文章，请点击阅读原文

长按二维码关注公众号